5 Minuten
Als ich vor etwa zwei Jahren bei Sparkteams anfing zu arbeiten, war ich begeistert vom Programmieren. Ich dachte, vielleicht würden funktionale Programmierung, Haskell, starke Typensysteme (und viele andere Dinge) die Art und Weise, wie wir als Industrie Software schreiben, verändern. Wenn es nur eine Möglichkeit gäbe, diese Dinge zu nutzen!
Ich erinnere mich noch gut daran, wie ein anderer junger Entwickler und ich bei einem Firmenessen enthusiastisch beschrieben, wie Rust und Haskell ganze Klassen von Fehlern ausschließen können! Die Reaktion unserer Kollegen konnte man bestenfalls als höflich interessiert bezeichnen. Damals habe ich das als eine Art Desillusionierung abgetan, eine Folge von zu vielen Jahren in dieser Branche in der man Java für “legacy” Anwendungen geschrieben hatte.
Jetzt, zwei Jahre später, denke ich anders. Was ich schnell als Desillusionierung abgetan habe, ist etwas anderes. Es ist der Fokus darauf mit Menschen etwas zu erschaffen. Der Kollege, der im übertragenen Sinne nur mit den Schultern gezuckt hat, spricht mit großer Freude darüber, wie sich bei einem unserer Kunden ein Team mit zwischenmenschlichen Reibungen und Fluktuationen in ein gut eingespieltes, freundliches und kooperierendes Team verwandelt hat. In ähnlicher Weise erlebe ich, wie viele leitende Angestellte sich wirklich darauf konzentrieren, Ergebnisse zu liefern.
Nach zwei Jahren bin ich immer noch ein begeisterter Verfechter der funktionalen Programmierung und anderer ‘shiny things’. Aber ich glaube, mein Eifer hat etwas nachgelassen. In letzter Zeit habe ich mich sogar dabei ertappt, dass ich für eine Technologie plädiert habe, die man nur als ‘boring’ bezeichnen kann. Rückblickend denke ich, dass ich am Shiny Thing Syndrom (ich habe diesen Begriff nicht erfunden) erlegen bin. Etwas, das unter uns Softwareentwicklern sehr verbreitet zu sein scheint.
Wie auch immer, zurück zu dem, worüber ich eigentlich schreiben wollte: Die Wahl der richtigen Technologie für die jeweilige Aufgabe. Um das Offensichtliche klarzustellen: Wenn wir uns entscheiden, eine Technologie zu unserem Stack hinzuzufügen, wollen wir ein Problem effizient lösen. Das bedeutet, dass die Technologie nicht nur unser Problem effektiv lösen muss, sondern auch, dass die Kosten über den gesamten Lebenszyklus hinweg gering sind, was Zeit und Geld angeht.
Das ist mein Punkt: Je größer dein Team wird und je mehr Erfahrungen ihr mit Ihrer aktuellen Technologie sammeln, desto teurer wird das Hinzufügen neuer Technologien. [Dan McKinley] (http://boringtechnology.club/) hatte die Idee der “Innovationstoken”. Innovationstoken sind eine imaginären Währung, von der man nur einen begrenzten Vorrat hat und die man jedes Mal ausgeben muss, wenn man eine neue Technologie zum Stack hinzufügen möchte.
Du fügst MongoDB zu deinem Stack hinzu? Das kostet 2 Token. Den Build-Prozess mit Gradle konfigurieren? Das ist ein weiteres Token. Ihre Anwendung in Closure neu schreiben? Oh blöd, es sind nicht genug Tokens übrig. Klingt düster? Das muss es nicht. Man kann auch Token zurückgewinnen, indem Sie man den Tech-Stack aufräumt. Brauchst dein Team wirklich drei verschiedene Bibliotheken zur JSON-Serialisierung? Durch die Vereinheitlichung könne ein Token zurückgewinnen. Oder die Entfernung der letzten halbfertige Implementierung eines weiteren session stores? Ein weiteres Token.
Kostenübersicht durch Innovationstokens
Wie berechnet man die Kosten einer Technologie in Innovationstokens? Ich habe versucht, eine kleine Reihe von Faktoren zu finden, die dabei helfen sollten.
-
Oberflächenkomplexität. Oder: Wie schwer ist es zu verstehen, was dieses Teil tut? Wenn ich einem neuen Teammitglied in ein paar Sätzen beschreiben kann, was diese Technologie tut, und diese Person sie dann produktiv nutzen kann, würde ich sagen, dass sie eine geringe Oberflächenkomplexität aufweist.
Dabei ist zu beachten, dass dies nicht unbedingt die gesamte Komplexität der Technologie ist. Nehmen wir zum Beispiel eine Bildbibliothek wie ImageMagick. Trotz der inhärenten Komplexität der Arbeit mit Bildern ist es einfach zu erklären, was sie tut.
-
Liability. Oder: Wie schwer ist es, das Teil durch eine Alternative zu ersetzen? Das ist es, was architektonische Innovationen so teuer macht.
-
Zukunftssicherheit. Oder, wie wahrscheinlich ist es, dass man die Technologie ersetzen muss?
-
Verbreitung. Oder: Wie etabliert ist diese Technologie? Etablierte Technologien haben gewisse Vorteile: Es ist einfacher, Mitarbeiter einzustellen, die sich mit der Technologie auskennen. Aber auch wenn du nicht vorhast, dein Team zu vergrößern, kann man davon profitieren ausgetretenen Pfade zu beschreiten.
Nehmen Sie zum Beispiel Spring. Es ist zwar nicht ‘shiny’, aber man sich sicher sein, dass jeder erdenkliche Fehler bereits gemacht und im Internet diskutiert worden ist.
Fazit
Diese Faktoren, die eine Technologie “langweilig” machen, können nicht allein bewertet werden, sie hängen von** Ihrer Branche**, Ihren Mitarbeitern und Ihrem vorhandenen Technologiepaket ab. Und natürlich müssen sie gegen den Wert, den sie mit sich bringen, abgewogen werden, z. B. Leistung oder Funktionalität.
In den nächsten Blogbeiträgen werden wir Ihnen einige Beispiele für die “langweiligsten” Technologien vorstellen, die wir bei unseren Kunden einsetzen. Beginnen werden wir mit einem Blick auf Maven.
